PATH
MacOS X Server Release Notes Copyright \xa9 1998 by Apple Computer, Inc. All Rights Reserved.
Mac OS X Server Developer Release Notes:
Application Layout Guidelines
The guidelines incorporated in this release note offer developers a way to improve the cross-release consistency of the layouts of application menus, windows, and dialogs. They focus mainly on Rhapsody application layout and currently provide only minimal information for Yellow Box for Windows. Interface Builder and Project Builder have incorporated these guidelines to simplify the layout process for menus, windows and dialogs (also known as panels).
Contents:
Menus and Menu Organization
Every application should contain the following menus (if they are applicable to the application) in left to right order: Apple, File, Edit, Window, Services and Help. Interface Builder and Project Builder provide these menus by default.
Apple Menu
This menu is not present on Yellow Box for Windows systems.
- The Apple menu should contain only one item, labeled "About
application-name ".
- No other application menu items should be present in the Apple
menu. Place help menu items or other application-information items
in the Help menu.
- Do not put the Preferences menu item in the Apple menu (see Edit menu).
File Menu
- If necessary, rename the File menu to something more
appropriate to the application (for example, the Terminal
application has a Shell menu).
- On Rhapsody systems, Quit, preceded by a separator, should
always be the last item of the File menu. On Yellow Box for
Windows platforms, this item should be named Exit.
- The default contents of the File menu are: New, Open..., [separator], Close, Save, Save As..., Revert, [separator], Page Setup..., Print..., [separator], Quit. While Close also exists in the Window menu, it's included here because it is a familiar location and it allows an alternative means for closing documents.
Edit Menu
- If your application supports Undo and Redo, they should appear
at the top of this menu, followed by a separator.
- On Rhapsody platforms, make the application-preferences menu
item (Preferences...) the last item of this menu, preceded by a
separator. On Yellow Box for Windows platforms, put the
Preferences... menu item in the Tools menu.
- The default contents of the Edit menu are: Undo, Redo, [separator], Cut, Copy, Paste, Clear, Select All, [separator], Preferences....
Window Menu
This menu was formerly named "Windows".
- If necessary, rename this menu to "Window" to conform to the
Win32 and Mac OS guideline.
- If necessary, update your application's menu to reflect the new recommended ordering: Close Window, Zoom Window, Minimize Window, <separator>, Arrange in Front (which should be Cascade on Yellow Box for Windows). At run time, the Application Kit appends a separator, followed by the list of current windows, by title.
Services Menu
The system manages the contents of this menu.
Help Menu
- By default, the Help menu contains the item "<your app
name> Help". Rename this item to a more appropriate label (for
example, "Terminal Help" or "Mailviewer Help"). You may add more
help menu items if you want to provide access to various sources
of information or pointers to multiple Help Viewer documents.
- On Yellow Box for Windows, the "About" menu item found in the Apple menu is in this menu. It is the last item, preceded by a separator.
Additional Menu Conventions
Beyond the basic menu items listed above, you may include additional items if they are applicable to your application. The following discussion limits prescriptions to placement and does not address the behavior or typical uses for these items.
- Save To...
- Place this menu item after Save As... in the File menu.
- Paste As...
- Place this menu item after the standard Paste item in the Edit menu. If this item only performs a single translation, change the name to reflect that (such as MailViewer's "Paste as Quotation").
- Find...
- If your application supports textual searches, it can use the predefined Find item and submenu. Put the Find item in the Edit menu after the text-manipulation group of menu items (Cut, Copy, Paste, Clear, and Select All). The default items and their ordering in the submenu are: Find..., Find Next, Find Previous, Enter Selection, Scroll to Selection.
- Spelling... and Check Spelling
- If your application supports spell checking, it can use these predefined menu items. Put these items in the Edit menu after the text manipulation grouping (Cut through Select All) or after Find it if exists. If used together, visually separate the spelling and find items with separators.
- Show Colors
- If your application supports color capability, it can include this menu item, which opens the Colors utility window. By default, this item exists as part of the Text submenu (see below), but if its function includes the assignment of colors to non-textual objects, then remove it from this submenu and place it in the appropriate first-level menu, usually the Format, Edit, or a content-editing menu specific to the application.
- Text
- If your application supports text editing, it can use this predefined menu item with its submenu. The default placement is in the Format menu (see below), but if this location is not appropriate, you can place this item in the Edit menu directly after the text-manipulation group (Cut through Select All), or in another content-editing menu specific to the application. The default menu items and their ordering in the submenu are: Align Left, Center, Justify, Align Right, [separator], Show Ruler, Copy Ruler, Paste Ruler.
- Font
- If your application supports text editing, it can use this predefined menu item plus its submenu. The default placement is in the Format menu (see below), but if this location is not appropriate, you can place this item in the Edit menu after the Cut through Select All grouping, or after Text if it exists, or in an application-specific menu. The default menu items and their ordering in the submenu are: Show Fonts, Bold, Italic, Underline, [separator], Kern, Ligature, Baseline, [separator], Show Colors, [separator], Copy Style, Paste Style.
- Format
- This predefined menu includes the Text and Font menu sets (see above) and it is typically used as a menu. When used as a menu, it should include other menu items relating to the attributes of a document's content such as Show Colors (if removed from the Text submenu). You should place Format after the Edit menu and before the Windows menu.
Yellow Box for Windows Menus
On Yellow Box for Windows, most menu items have underlined "mnemonics." The default menus you get from Interface Builder or Project Builder have the correct mnemonics for most menu items. For custom menu items, choose unique mnemonics as appropriate.
The best way for cross-platform developers to ensure correct menus on Yellow Box for Windows as well as for Rhapsody is to use two nib files for the menu. The one for Rhapsody is named nibName.nib while the one for windows is named nibName-windows. Interface Builder automatically gives you the correct menu layout for Yellow Box for Windows. In the application's Preference panel, select "Windows Inteface style" mode and then create the nib. These nib files should only contain your menu and related object to avoid unnecessary duplication of human-interface objects. In future releases we will provide a better cross-platform solution for allowing one definition of a menu to apply to applications on both platforms.
To summarize other menu differences on Yellow Box for Windows:
- The Apple menu does not exist.
- The "About" menu item found in the Apple menu is in the Help
menu. It is the last item, preceded by a separator.
- The Quit item in the File menu should be named Exit.
- The Preferences... menu item goes in the Tools menu.
- The "Arrange in Front" item in the Rhapsody Window menu is named Cascade.
Menu and Button Naming
Ellipses
According to the dictionary, the term "ellipsis" means "1. the omission of one or more words that are obviously understood but that must be supplied to make a contruction grammatically complete 2. mark indicating an omission." The guideline for using an ellipsis keeps to the sense of these definitions. Basically, an ellipsis after a menu item or button label indicates that additional information is required to complete the command.
The ellipsis guideline should be applied consistently to both Mac OS Allegro and Rhapsody components. Because it also corresponds to the Win32 human-interface guidelines, no changes to menu items with an ellipsis will be required for Yellow Box for Windows nibs.
You should include an ellipsis with menu items or buttons that result in the following conditions:
- An action that requires further user input to complete, or
presents an alert allowing the user to cancel the action.
Typically these windows are modal and are dismissed after the user
completes the action. Examples:
-
Open...
Page Setup...
Print.... - An action that opens a non-modal dialog that expects
additional user input to complete its function. Examples:
-
Find...
Go To...
Spelling.... - An action that opens a settings window. Settings windows
typically let the user change some aspect of the application but
not document content. These dialogs are not primarily intended to
provide information (see Opening Informational Windows, below).
Examples:
Set Title...
Preferences...
Options...
There should be no ellipsis on menu items or buttons that result in the following conditions:
- An action that requires no further user input to complete and
does not present an alert. Often the item to be acted upon is
already selected. Examples:
New
Cut
Bold
Print One
Quit - An action that opens an informational, accessory, or tool window. These windows can be implemented as either utility windows (for example, Colors) or non-modal windows (such as Help, About, Fonts and Inspector). These windows provide tools that help users create or manage the content in the main window; they are frequently left open to assist the task of the main window.
Using "Show"
You should use the word "Show" with commands that open accessory windows. Detailed guidelines are:
- Use "Show [command]" in menu items or button labels to
indicate that an accessory window will be presented. Often these
item's names are nouns. Examples include: Show Colors, Show Fonts,
or Show Console.
- Do not use "Show" if the item's name is a verb or implies an action. Examples include Spelling... and Find....
Additional Conventions
Other menu- and button-naming conventions include:
- When a menu or button command updates application content or
commits changes in a dialog, the term "Apply" is preferred over
"Set". You may use Set in a button or menu item when it is the
initiating command, such as "Set Window Title" which might present
a modal dialog.
- When a menu or button command presents a set of choices to the user (such as opening a file browser to set a path), the term "Select" is preferred over "Choose".
Shortcut Keys
There are a basic set of shortcut keys that you should use consistently. For the most part, these shortcuts are consistent with Mac OS and Windows conventions.
- For menu items, refer to the shortcuts provided by Interface
Builder's default application nib.
- For dialogs that contain a default button, the Return or Enter
keys should trigger that button.
- For non-modal dialogs (that is, dialogs with no Cancel
button), you may use the Enter key to to commit entries when text
is entered or modified.
- Escape should map to a dialog's Cancel button if one exists.
Note that in some contexts the Escape key is used as a "complete"
key. It can continue to be used in such a manner if no Cancel
button is present.
- The trigger key when keyboard navigation is being used is the spacebar.
Window Types and Uses
Rhapsody provides a variety of window types and each has a set of characteristics intended to support that window's role in the design of an application.
Document Windows
This is the most common type of window in Rhapsody; almost every application will contain at least one document window. The document window is modeless and always appears in the Window menu's window list.
Alerts
Rhapsody provides a system alert dialog, generated programmatically by the Application Kit. All applications are expected to use this standardized alert in most circumstances. Alerts are application modal and can support up to three buttons. A detailed description on the use of a Alert can be found in the Macintosh Human Interface Guidelines (see For Additional Information, below).
Custom Alerts might be required when the standard Alert's features do not provide enough flexibility.
Modal Dialogs
Standardized system panels (such as Open, Save, Page Layout and Print) are provided by the Application Kit although applications have limited flexibility in customizing these panels. A detailed description on the use of a modal dialog can be found in the Macintosh Human Interface Guidelines (see For Additional Information, below).
Modeless Dialogs
Modeless dialogs are accessory document windows that provide additional controls to support the current task in the application's document windows. These windows are not modal, and can be made to hide when the application is no longer frontmost, although leaving them visible is sometime desirable if the window contains status or other information pertinent to other applications. Modeless dialogs can be made key but they do not appear in the Window menu's window list. Examples of modeless dialogs include Fonts, Spelling and Inspectors.
Utility Windows
Utility windows are small accessory windows or palettes that provide additional tools or controls to support the task in the application's document window. These windows always float on top of other application windows and always hide when the application is not frontmost. Utility windows can be made key but they do not appear in the Window menu's window list. An example of a utility window is Colors.
Font Preferences
Rhapsody provides eight font preferences. Note that on Yellow Box for Windows, most font preferences are picked from the system, so some of the default fonts listed below do not apply. The default values for each of the font preferences are:
|
Preference |
Default Font |
|---|---|
|
User (Application) Font |
Helvetica Medium (12) |
|
Fixed Pitch Font |
Ohlfs Medium (10) |
|
Menu Font |
Charcoal Regular (12) |
|
Title Bar Font |
Charcoal Regular (12) |
|
Message Font |
Charcoal Regular (12) |
|
Palette Font: |
Helvetica Bold (10) |
|
Tool Tips Font |
Helvetica Medium (10) |
|
Control Content Font |
Helvetica Medium (12) |
Note
When doing dialog layout, be sure to set your font preferences to these defaults. Also, default font sizes can be overridden by IB or PB when constructing windows or dialogs (see Control to Font Preference Mapping, below).
Control-to-Font Preference Mapping
Each control in an application must map to the appropriate font preference. This mapping allows users to change their font preferences and have all controls in all applications assume the desired change. The control-to-font preference mapping guidelines are:
|
Controls |
Font Preference |
|---|---|
|
Menubar, pull-down and pop-up menus |
Menu Font (set to 12 point) |
|
Window and dialog titlebar label |
Title Bar Font (set to 12 point) |
|
Utility window title bar label |
Palette Font (set to 10 point) |
|
Dialog static text title |
Message Font (set to 18 point) |
|
Push Button label |
Message Font (set to 12 point) |
|
Pop-up button label |
Message Font (set to 12 point) |
|
Text field contents plus label |
Message Font (set to 12 point) |
|
Radio button matrix label |
Message Font (set to 12 point) |
|
Check box button label |
Message Font (set to 12 point) |
|
Group box title |
Message Font (set to 12 point) |
|
ComboBox field content |
Message Font (set to 12 point) |
|
Tool Tips text content |
Tool Tip Font (set to 10 point) |
|
Static text for informational purposes |
Tool Tip Font (set to 10 point) |
|
Simple lists (names, settings, etc.) |
Message Font (set to 12 point) |
|
Browsers and table views |
Control Content Font (set to 12 point) |
|
Any control that requires fixed pitch |
Fixed Pitch Font (set to 10 point) |
|
Multi-line or scrolling text field: |
User font (set to 12 point) |
Charcoal is provided with only 12 point and 18 point bitmaps; you should therefore use it only in one of these two sizes. Alerts, which used to use 14 point fonts, should now use 12 point.
There are further guidelines for font preferences in text-entry fields, lists and tables. The appropriate font preference for these controls depends on the context of the control. For example, if a scrolling list of settings is presented alongside other controls that employ the Message font (push buttons, radio button matrix, and so on), then the Message Font preference should be used. If a scrolling list is used alone, or in conjunction with a browser or table view, or if space is an issue, then the Control Content Font preference is preferable.
Control Sizing
Your application should conform to a very basic set of guidelines for sizing controls. To simplify the process of resizing and repositioning existing layouts, a decision was made to base most values on a 6-pixel grid. In addition, many of the existing default control sizes, as defined in Interface Builder, are retained. There are some exceptions to this, however:
- Push buttons
- These controls should be 24 pixels tall. The minimum width of a push button is 66 pixels. To obtain the proper button width for longer buttons, in Interface Builder, select the control and choose Format>Size>Size to Fit; then add 12 pixels to the width and round the result (up or down) to the nearest multiple of 6.
- Pop-up buttons
- These controls should be 20 pixels tall. To obtain the proper button width, in Interface Builder, select the control and choose Format>Size>Size to Fit; then add 12 pixels to the width and round (up or down) to the nearest multiple of 6.
- Check boxes and radio buttons
- These controls should have an 18-pixel baseline-to-baseline spacing. If existing button matrices are set to the default Message Font (Charcoal 12), this value should become 19. Remove the single pixel intercell space manually.
- Bevel buttons
- The minimum size of these controls should be no smaller than 20 pixels square when used together with other button types or text controls.
- Text input fields
- These controls should be 22 pixels tall if the input text font is Charcoal Regular 12. Charcoal is the default text input font, but you can use the User Font preference if the field supports multiline input.
- Lists (including browsers and table views)
- You should vertically size these controls to show full lines of text only and no fractional lines of text. Using the default font, you can calculate this value with the formula (number of lines x 16) + 4.
When you create or change dialog layouts, always remember to use the default font preferences (see Font Preferences, above).
Control Positioning and Other Dialog Layout Issues
As with control sizing, the layout of dialogs uses a 6-pixel grid since most spacing is based on a multiple of 6.
- In common document windows that contain a single view (for
example, scrolling text or tables), there should be no border
between the window frame and the frame of the view.
- In common dialogs that contain a mix of controls, assume a
12-pixel border between the controls and the window frame.
- For group box contents, no control should be positioned within
12 pixels of the box's border.
- Horizontal spacing between controls and groups of controls is
12 pixels. Exceptions include the space between text-field labels
and their associated text fields, and text fields and their
associated pop-up buttons.
- Vertical spacing between controls and groups of controls is 12
pixels. Exceptions include stacked controls of a common type (such
as text fields or push buttons), where 6 pixels is preferred.
- Bevel buttons, when used in a toolbar, can be butted against
one another. The design of the bevel button accommodates this
arrangement.
- You should position the default button for window, dialog or alert (typically OK) in the bottom-right corner. If the object also includes a Cancel button, position it left of the default button. If there is a third, or alternate, button (for instance, "Apply"), position it left of the Cancel button. The preferred ordering of buttons, based on their functionality is: Alternate, Cancel and Default ("Apply", "Cancel", "OK").
Avoid the excessive use of group boxes. Group boxes are valuable when they are used sparingly. Use them when you need to relate visually and separate a number of controls from other controls in the same dialog.
Double Black Lines and Control Clipping
A characteristic of the Apple platinum appearance is a one-pixel black border around most controls. Problems arise when two controls are butted against each other, resulting in either a two-pixel black line or one control obscuring (clipping) the view of the neighboring control. This situation commonly occurs when a scrolling text view is placed within a window and positioned against the window's frame or when two scrolling views are placed side-by-side.
- Scroll views that are intended to occupy an entire window can
avoid the double-frame problem by turning off the border of the
view.
- Other types of controls have a exterior single-pixel frame
which is used to create the "beveled" appearance. This attribute
becomes a problem when two controls that share this attribute are
intended to share a common border. For some controls, you can
solve this problem by turning off the beveled appearance of both
controls or the frontmost control.
- Table views and browsers need to have their borders "tucked
under" the window frame's interior border (by 2 pixels) to avoid
the double-frame problem. Note that scroll views, lists, and text
fields have a single pixel "bevel" outside of the actual control
content region (as defined by the black frame). This bevel region
is what should be hidden when the view is intended to occupy the
full window.
- Tab panes that occupy the full width of the window can avoid double frames by setting the edges of the pane under the window frame's interior border.
For Additional Information
While these guidelines supersede earlier Mac OS Human Interface guidelines, they represent a subset of the total information available in the Macintosh Human Interface Guidelines and the Mac OS 8 Human Interface Guidelines documents. Refer to these documents for detailed information on control behaviors, application human-interface design, and localization.
The Macintosh Human Interface Guidelines and Mac OS 8 Human Inteface Guidelines can be found at: http://devworld.apple.com/techinfo/techdocs/mac/mac.html
Microsoft's Win32 guidelines can be found at: http://www.microsoft.com/win32dev/uiguide/default.htm